Single Blog

Este artículo es una traducción de un post de Frédéric Faure (arquitecto de sistemas en Ysance) sobre las diferencias entre utilizar una infraestructura de computación en la nube como AWS y construir la propia física. Lo informamos porque creemos que el artículo es muy correcto.

He notado muchas preguntas sobre las diferencias inherentes a la elección
entre una infraestructura en la nube como AWS (Amazon Web Services) y un
infraestructura física tradicional. En primer lugar, hay una serie de
nociones preconcebidas sobre este tema que trataré de descifrar para ti.
Entonces, hay que entender que cada infraestructura tiene sus ventajas y
Desventajas: Una infraestructura en la nube típica no tiene por qué cumplir necesariamente sus requisitos
requisitos en cualquier caso, sin embargo, debe ser capaz de cumplir algunos de ellos
Optimizando o facilitando las funcionalidades que ofrece una infraestructura física tradicional. A continuación, demostraré las diferencias que he notado entre los dos métodos, con el fin de ayudarle a tomar su propia decisión.

El marco

Nube

Hay diferentes tipos de posibilidades para usar la nube y continuaré hablando de AWS, que son
servicios orientados a la infraestructura, en lugar de servicios del tipo Google (GAE – Google App Engine),
por nombrar uno, que proporciona un entorno de ejecución para sus aplicaciones web desarrolladas con
las API proporcionadas (similares a un marco). En realidad, en lo que respecta a estos últimos, no podemos hablar por los clientes (los que usan la tarjeta de crédito) sobre la gestión de la infraestructura, porque cargamos nuestra aplicación utilizando las API proporcionadas y dejamos toda la gestión de la infraestructura al proveedor de servicios. Esto no quiere decir que se trate de un servicio menor de computación en la nube, sino simplemente otro tipo de servicio en la nube, más orientado a la PaaS de orientación a la infraestructura.

Infraestructura física

En lo que respecta a las infraestructuras físicas, examinaré el concepto de infraestructuras autoalojadas y, al mismo tiempo, la noción de infraestructura mantenida por un proveedor de alojamiento. Del mismo modo, me centraré en las infraestructuras basadas directamente en hardware, así como en las basadas en entornos virtualizados . La computación en la nube también se basa en la virtualización, pero no estamos tan interesados en esa tecnología aquí, sino en la forma en que se entrega a los clientes (usted). De hecho, simplemente puede lanzar instancias a través de una consola, como lo hace para EC2, si tiene un ESX (VMware), por ejemplo, pero es «solo» un hipervisor que divide el servidor físico en varias máquinas virtuales. Todavía tendrá que lidiar con la compra de equipos (blades, etc.), la configuración de la red, etc. Pero volveremos a esos detalles más adelante.

Computación en la nube = ¿Administradores de sistemas rebajados?

¡Sí, las ventas están en marcha! ¿Estás buscando un suéter, una chaqueta, … ¿Un administrador de sistemas? A menudo se encuentra con personas que piensan que la nube (en el caso de AWS) les permitirá habilitarlos sin un administrador de sistemas experimentado y construir una infraestructura con menos experiencia. La respuesta es obvia: ¡INCORRECTO!

Tal vez un argumento de venta inteligente pueda convencerlo de que los diversos servicios son tan fáciles de usar, que puede hacerlo todo usted mismo y que las AMI preempaquetadas (Amazon Machine Image) le facilitarán la vida, pero no hace falta decir que una vez que lanza sus instancias EC2, se conecta a las computadoras (SSH / puerto 22 para Linux y TSE / puerto 3.389 para Windows), Luego tendrás que establecer parámetros, hacer la afinación, etc.

Lo que es cierto para los administradores de sistemas frente a AWS también lo es para los arquitectos de sistemas en el campo de los servicios de computación en la nube que dan acceso a las capas más altas (PaaS como Google App Engine). Es necesaria una persona con experiencia en el campo, capaz de configurar los requisitos de infraestructura: la herramienta puede cambiar, pero las habilidades deben seguir estando disponibles. Tenga en cuenta, sin embargo, que si utiliza
GAE, no necesita un administrador de sistemas para la aplicación. Si el Editor de servicios en la nube ofrece un servicio en un nivel determinado (Haas, IAAS, PaaS, etc.), ya no es necesario que el personal administre las capas inferiores. Sin embargo, aceptamos el marco proporcionado por el proveedor de la nube.

Los administradores de sistemas no pueden ser eliminados, pero su papel está cambiando: se están convirtiendo en algo más que un desarrollador. De hecho, poder tirar de recursos sobre la marcha permitirá una gestión de la infraestructura programable y automatizable a través de scripts, que llamarán a las APIs proporcionadas por Amazon que permite la comunicación con sus servicios web. Todo en Amazon es webServices: EC2, EBS, SQS, S3, SimpleDB: la única operación no SOAP o REST que existe es cuando nos conectamos directamente a las instancias EC2 que hemos invocado a través del WebService o cuando las instancias EC2 hablan con el EBS que hemos invocado a través del … Te dejaré adivinando.

El administrador puede entonces, en lugar de ir a la sala de servidores, añadir un disco, conectar un servidor (en el caso de una arquitectura física) o coger el teléfono y pedir al proveedor de alojamiento que lo haga (tomar un café … Llame de nuevo… tomar un Xanax o una pastilla de Prozac…), solicitar recursos a través de un script en Ruby o Python… Así podrás automatizar la infraestructura Cloud y mucho, mucho más, además, con una serie de scripts y herramientas.

Por lo tanto, la profesión del administrador de sistemas está evolucionando entre una infraestructura física y una infraestructura en la nube como AWS: siempre será más que un desarrollador. Sin embargo, los administradores de sistemas siguen siendo esenciales.

¡Elastic es genial!

Como decía antes, una de las diferencias esenciales entre ambos tipos de infraestructuras es la flexibilidad y el dinamismo que aporta la solución Cloud, frente a una arquitectura física tradicional (ya sea basada en virtualización o no). Esto significa la eliminación del tiempo
Necesario para instalar y configurar la logística (compra de equipos, instalación del sistema operativo, conexión a la red – red física y configuración de interfaces, etc.) Del mismo modo, cuando
ya no necesita una pieza de hardware (una instancia virtual EC2, un volumen EBS, un objeto S3, etc.), puede devolverlo al grupo de recursos: se reinicializará para que no se pueda recuperar ninguno de sus datos, y
vuelve a estar disponible hasta la próxima llamada al servicio web.

También tiene acceso completo a ciertos elementos, como los grupos de seguridad (firewalls) establecidos para cada instancia… Y esto es muy útil. Es muy práctico, especialmente en comparación con un proveedor de alojamiento tradicional: ¿recuerdas la última vez que tuviste que cambiar las reglas de tu firewall?

Pero no se trata solo de los pros y los contras de comprar el servidor en comparación con las instancias en ejecución. Los servicios de AWS están respaldados por centros de datos que ya están organizados y probados industrialmente. Todas las normas de seguridad
que debe cumplirse en términos de protección contra incendios, refrigeración de los sistemas, redundancia eléctrica de la fuente de alimentación, seguridad física contra robos, distribución del hardware en 2 o más
Los centros de datos físicos para la recuperación de desastres, etc. implican una inversión inicial y colosal, incluso cuando todo está instalado, aún no podrá recrear la misma calidad dentro de su empresa
(99% de las veces, en cualquier caso). Sin embargo, puede lograr todo esto, o parte de ello, con un proveedor de alojamiento tradicional.

Pero también están todos los servicios tipo software, como la duración de la gestión de datos (Redundancia/Replicación, en EBS y en S3), la accesibilidad o alta disponibilidad, la monitorización del hardware (para recibir una alerta cuando los componentes físicos muestran signos de debilitamiento), los procedimientos
por averías, etc. Te dejaré leer los 9 principios de S3 (versión en francés), para entender cuánto conceptos se incluyen. No lograrás todo eso con un proveedor de alojamiento tradicional (y olvidarte de ti @Home). La calidad del servicio S3 es en realidad una gran ventaja, especialmente en comparación con los precios actuales… ¡Hablemos de precios!

Costos

No hay reglas fijas. Con la nube, pagas por el recurso por hora y cuando ya no lo usas, dejas de pagar. Las instancias también se pueden reservar por un año o tres años: instancias reservadas: pagas una tarifa al principio y luego pagas la tarifa de uso a una tarifa subsidiada, lo que te lleva a un punto de no retorno de un determinado
Porcentaje de utilización de recursos a lo largo del año (o tres años).
Para calcular fácilmente cuánto le costará su infraestructura, utilice la nueva calculadora proporcionado por Amazon. En todos los casos, una parte está relacionada
al uso horario y otro al tráfico/volumen almacenado.

Puedes comparar el costo de tu infraestructura local o tu hosting
proveedor. El precio fijo de la nube es particularmente atractivo en los siguientes casos:

• El precio establecido es imbatible para ProofOfCconcepts, eventos/presentaciones o arquitecturas de pruebas de carga/validación.
• Es muy atractivo para aplicaciones o APIs montadas sobre un modelo económico de tipo SaaS y para las que se necesita gastar dinero en recursos solo cuando el cliente paga por usar las APIs anteriores.
• Es un buen precio para las aplicaciones sociales en Facebook, por ejemplo, que pueden despegar de la noche a la mañana para los fenómenos de las redes sociales y puedes experimentar auges (o caídas) en las visitas.
• También es conveniente cuando lanzas una nueva empresa, o un proyecto específico dentro de una entidad más grande y no quieres invertir mucho en logística desde el principio.

Para todos los otros casos específicos, tendrá que hacer sus propios cálculos.

¿Ralentizar? O, por supuesto, no………

Por lo general, independientemente del tipo de infraestructura que tenga, se deben instalar los mismos componentes y mecanismos. Sin embargo, hay que reconocer que, a menudo, los aspectos acogedores de una infraestructura alojada en «casa» pueden llevar a una falta de rigor en muchos aspectos. El hecho de que Amazon, con su AWS, ofrezca una solución dinámica y volátil para estos EC2, obliga a instalar mecanismos (que deberían ser estándar) para plantearse un plan de recuperación de fallos o desastres más graves, dada la naturaleza volátil de la herramienta, y para identificar datos importantes con el objetivo de garantizar la durabilidad de los datos (EBS, Copias de seguridad de S3, etc.)

Redes y recursos compartidos

La red es un elemento importante … ¡Y en más de un sentido! De hecho, la configuración de la nube ya está preparada para usted, y esto es conveniente. Pero esto también significa que no
controles y, en consecuencia, no es posible controlar y, por lo tanto, diagnosticar, por ejemplo,
las causas de una desaceleración. Existe una falta de transparencia similar respecto a los recursos compartidos en una nube: a nuestro nivel no es posible estimar el impacto de otras personas que utilizan el recurso que compartimos (como el ordenador físico en el que se basa nuestra instancia EC2, el dispositivo físico que utilizamos como periférico conectado a la red EBS, la red de ancho de banda, etc.). La única supervisión posible se limita a las funciones de entrada/salida de la instancia (por ejemplo, un EBS es un dispositivo conectado a la red, por lo que … no hay posibilidad de verificar las condiciones de conectividad, solo con la E/S de los discos). La monitorización que se puede hacer se centra en la máquina virtual EC2 (la instancia es gestionada por un hipervisor basado en virtualización Xen). Por lo tanto, la visibilidad total de nuestra infraestructura no es posible en una nube. Esto hay que tenerlo en cuenta… y aceptado, si desea implementar su arquitectura en la nube. También debe evaluar la misma falta de transparencia para otros recursos compartidos que se mencionó anteriormente (uso de EBS, etc.)

Del mismo modo, una multidifusión no es posible cuando se trata de protocolos de comunicación: recuerde que para algunos clústeres. Esta limitación es comprensible, dado el impacto de gran alcance que puede tener una mala gestión de la multidifusión.

Esto se debe a la forma en que opera la Nube: tiene formas sencillas, que enmascaran un cierto número de elementos que ya no controlaremos.

Soporte de guardia, monitoreo, BCP (Business Continuity Planning) y sanciones

Una pregunta que me han hecho a menudo: «¿Amazon proporciona un servicio de soporte telefónico (con respecto a sus aplicaciones/infraestructura que se ejecutan en AWS)? «La respuesta es no. AWS (Estados Unidos) Tiene que ser visto como un conjunto de herramientas ofrecidas por Amazon que garantiza que estas herramientas estén siempre encendidas y que funcionen bien. Apoyan estas herramientas y el desarrollo de sus diferentes funciones. Sin embargo usted es el responsable de utilizar las herramientas (en cualquier caso no son propietarias de las claves privadas delas instancias EC2…), por lo que no hay un paquete de monitorización/soporte de guardia/BCP (Business Continuity Planning).

A diferencia de los contratos específicos que puedes firmar con el proveedor de alojamiento, tienes que proporcionarles información sobre ti, o sobre el servicio de soporte de guardia, por ejemplo, puedes subcontratarlo a empresas de gestión. Lo mismo ocurre con la monitorización: Amazon ofrece Amazon CloudWatch, pero la información (% de CPU, lecturas/bytes escritos en el disco y bytes de entrada/salida de la red) es demasiado concisa para una comprobación adecuada como esperan Centreon/Nagios, Cacti, zabbix o Munin. El CloudWatch
es utilizado por Auto Scaling, pero no reemplaza el monitoreo real. Alguno
Los proveedores de alojamiento tradicionales ofrecen paquetes de monitoreo como sus servicios.

En cuanto al BCP y las penalizaciones relacionadas, el monto debe alojarse internamente: usted es responsable de los recursos y de cómo administra los fracasos / recuperación de desastres, en línea con las capacidades de las herramientas (el AWS). Aquí es donde es importante comprender la naturaleza global de la arquitectura de servicio de Amazon: si no entiendo cómo funciona la herramienta, no podrá implementar un BCP efectivo. En cuanto a las penalizaciones, no tienen nada de inusual: simplemente significan una pequeña factura por el mes en el que estás en la categoría de «Servicio no disponible» definida por los criterios de Amazon. Esto no tiene nada que ver con las penalizaciones basadas en las sumas perdidas por falta de disponibilidad.

Es absolutamente necesario considerar los servicios web de Amazon como una herramienta. Si bien existe el soporte de AWS (al que puede llamar para preguntas y problemas a nivel de herramienta) por el que puede pagar, nunca obtendrá todo el potencial contractual que tendría con un proveedor de alojamiento más tradicional y, en general, es responsable de su arquitectura en todos los niveles (incluida la seguridad de sus instancias: de la pérdida de llaves!).

Seguridad

Seguridad… a menudo un tema tabú, tan pronto como comienzas a hablar de Cloud Computing. No me refiero a la integridad de los datos almacenados o incluso a la gestión del acceso en instancias virtuales de las que somos responsables, me refiero a la confidencialidad de los datos almacenados en diferentes servicios (S3, EBS, EC2, SQS, etc.) o de los datos en tránsito entre dichos servicios.

El primer punto clave es que el nivel de seguridad con el que están equipados los centros de datos de Amazon, no solo físicamente sino, lo que es igualmente importante, en términos programáticos, siempre estará muy por delante de su promedio
CED, incluso el centro de datos del más pequeño de los proveedores de alojamiento. En primer lugar, porque es un negocio de Amazon: un problema de seguridad revelado en su infraestructura tendría consecuencias inmediatas en términos de reacciones de los usuarios (y, por lo tanto, en términos de negocio). Por lo tanto, se trata de un detalle esencial, sobre todo porque Amazon tiene que demostrar su valía en este ámbito tan sensible y, por lo tanto, está obligado a hacer todo lo posible para ganarse a sus clientes. Además, el propio número de sus instalaciones les permite poner en común sus inversiones en seguridad y hacerlas amortizarse: esto
No es concebible para empresas más pequeñas, o empresas que no se especializan en ello. Por lo tanto, Amazon tiene los medios y la obligación de garantizar la seguridad.

Lo que causa mi escepticismo es que la Nube no es fácil de controlar. Hay que tener fe. No es más arriesgado que depositar tu confianza en un proveedor de alojamiento tradicional, o en tu equipo interno…
¡Pero es completamente nuevo! Así que, ¡cuidado! Una reacción normal. Pero tal vez esta sea precisamente la oportunidad para que trabajemos en la seguridad a nuestro nivel, algo que a menudo se pasa por alto, debido al exceso de confianza o la falta de interés. La primera tarea es cifrar la información: los datos almacenados y los datos en tránsito. Recuerde tener en cuenta la carga de la CPU de cifrado/descifrado. La segunda
es comprender completamente los mecanismos de seguridad de los distintos servicios de Amazon:

Autenticación multifactor de AWS

• Credenciales de acceso: Claves de acceso, X.509 Certificados y pares de claves
• Credenciales de inicio de sesión: dirección de correo electrónico, contraseña y dispositivo de autenticación multifactor de AWS
• Identificadores de cuenta: ID de cuenta de AWS e ID de usuario canónico

A continuación, tendrás que seleccionar el personal que estará autorizado a acceder a las diferentes claves de seguridad.

Conclusiones

La evolución de las funciones en la gestión de infraestructuras se puede ver claramente en esta primera parte: desde la gestión de los recursos físicos mediante APIs, mecanismos que garantizan la durabilidad de los datos,
disponibilidad de servicios, etc. hasta la provisión de energía del servidor y la seguridad física del centro de datos, todos los cuales están respaldados de manera transparente.

Resultado final: «sólo» tenemos que usar APIs que se comuniquen con un servidor remoto. Esta es la diferencia con la infraestructura física. La virtualización (que es un aspecto de AWS) que conocemos y que ya se utiliza desde hace tiempo, la utiliza Amazon: no se trata tanto de una revolución técnica -aunque no niego la complejidad de la implementación y el soporte que hay en ella- como del servicio que se ofrece con ella, que aporta un verdadero valor añadido. Se combina con un nuevo modelo económico de pago por uso (como servicio). Esto ha permitido la aparición de algunas aplicaciones (como los juegos que se encuentran en las redes sociales), que de otro modo se habrían visto comprometidas por la inversión inicial.

Los servicios prestados por el Cloud Computing traen consigo inevitablemente una cierta reducción del grado de control y visibilidad sobre algunas partes de las infraestructuras, en particular en la red. Este es el precio que debes
El salario, ya sea completamente insignificante o realmente problemático: todo depende de sus necesidades.

AWS debe verse como una herramienta completa, pero no nos libera de tener que seguir todas las mejores prácticas ni obtener todos los componentes estándar de una infraestructura: servidores de registro, monitorización, BCP, gestor de configuración, etc. Todos estos elementos son y seguirán siendo su responsabilidad. No tenga expectativas demasiado ingenuas: como AWS ofrece Haas e IAAS, aún necesita un administrador de sistemas competente, y uno en particular que comprenda completamente la arquitectura de AWS (de lo contrario, podría sentirse decepcionado): si cambia de GAE (Google App Engine), aún necesitará un arquitecto que comprenda completamente la arquitectura de GAE, etc. El negocio es
en constante evolución.

En lo que respecta a la seguridad de AWS, estoy razonablemente seguro. En primer lugar, debe enfatizarse que la información y los datos probablemente estén menos seguros dentro de su empresa que los confiados a Amazon (de todos modos, en la mayoría de los casos, no generalizo). La exposición de AWS a Internet y el compromiso de Amazon con los negocios significa que Amazon se toma muy en serio la seguridad. Además, usted es responsable de una gran parte de esta seguridad (gestión de claves, etc.) y créame, esa es definitivamente la característica más riesgosa. Cuando se trata de transferencia y almacenamiento de datos, piense en «cifrado».